One-tap payment using a contactless card

ABSTRACT

An authentication application may receive, from a merchant application of a client device, a merchant identifier, a transaction identifier of a transaction, encrypted data, and a location of the client device. The authentication application may decrypt the encrypted data based at least in part on a private key. The authentication application may determine that the contactless card has been used to make a previous purchase with the merchant and that the location of the client device is within a threshold distance of a known location associated with a contactless card. A virtual account number generator may generate a virtual account number and transmit the merchant identifier, the transaction identifier, the virtual account number, an expiration date, and a card verification value (CVV) to a merchant server associated with the merchant to process the transaction using the transaction identifier, the virtual account number, the expiration date, and the CVV.

RELATED APPLICATIONS

This application is a continuation of U.S. patent application Ser. No.16/681,733, filed Nov. 12, 2019, which is a continuation of U.S. patentapplication Ser. No. 16/265,974, filed Feb. 1, 2019, titled “ONE-TAPPAYMENT USING A CONTACTLESS CARD”. The contents of the aforementionedapplications are incorporated herein by reference in their entirety.

RELATED APPLICATIONS

This application is a continuation of U.S. patent application Ser. No.16/265,974, titled “ONE-TAP PAYMENT USING A CONTACTLESS CARD” filed onFeb. 1, 2019. The contents of the aforementioned application areincorporated herein by reference.

TECHNICAL FIELD

Embodiments herein generally relate to computing platforms, and morespecifically, to tapping a contactless card to a computing device toperform one-tap payment.

BACKGROUND

Users often complete transactions using online software platforms.Conventionally, users must manually enter all relevant paymentinformation in the online software platform to complete a transaction.However, users often make mistakes when entering their paymentinformation. Furthermore, transmitting payment information via a userdevice may pose security risks.

SUMMARY

Embodiments disclosed herein provide systems, methods, articles ofmanufacture, and computer-readable media for tapping a contactless cardto a computing device for one-tap payment. In one example, anauthentication application may receive, from a merchant application of aclient device, a merchant identifier, a transaction identifier of atransaction, encrypted data, and a location of the client device. Theauthentication application may verify the encrypted data by decryptingthe encrypted data based at least in part on a private key for acontactless card. The authentication application may determine that thecontactless card has been used to make a previous purchase with themerchant and that the location of the client device is within athreshold distance of a known location associated with the contactlesscard. A virtual account number generator may generate a virtual accountnumber and transmit the merchant identifier, the transaction identifier,the virtual account number, an expiration date, and a card verificationvalue (CVV) to a merchant server associated with the merchant to processthe transaction using the transaction identifier, the virtual accountnumber, the expiration date, and the CVV.

BRIEF DESCRIPTION OF THE DRAWINGS

FIGS. 1A-1C illustrate embodiments of a system to tap a contactless cardto a computing device for one-tap payment.

FIGS. 2A-2D illustrate embodiments of tapping a contactless card to acomputing device for one-tap payment.

FIG. 3 illustrates an embodiment of a first logic flow.

FIG. 4 illustrates an embodiment of a second logic flow.

FIG. 5 illustrates an embodiment of a third logic flow.

FIG. 6 illustrates an embodiment of a fourth logic flow.

FIG. 7 illustrates an embodiment of a computing architecture.

DETAILED DESCRIPTION

Embodiments disclosed herein provide secure techniques to use acontactless card for one-tap payment. For example, when using a merchantapplication executing on a computing device, a user may select one ormore items for purchase. The user may then tap their contactless card tothe computing device, which may cause the contactless card to comewithin communications range of the computing device. Doing so causes thecontactless card to generate encrypted data which is transmitted to thecomputing device. The merchant application may receive the encrypteddata generated by the contactless card and transmit the encrypted datato an authentication server for validation. The merchant application mayfurther transmit an indication of a merchant identifier and/or atransaction identifier with the encrypted data. Once validated, theauthentication server may instruct a virtual account number server togenerate card data for the account associated with the contactless card.The card data may include a virtual account number, an expiration date,and a card verification value (CVV). A virtual account number may be anaccount number that is different than the account number associated withthe contactless card. The generated card data may then be transmittedwith the merchant identifier and the transaction identifier to amerchant server associated with the merchant. The virtual account numberserver and/or the authentication server may also provide a name of theuser, a billing address of the user, and/or a shipping address of theuser to the merchant server. The merchant server may then complete thetransaction using the received data. The merchant server may thentransmit a confirmation to the computing device which is outputted fordisplay by the merchant application to the user. From the point of viewof the user of the computing device, once the card is tapped to thecomputing device, the transaction is completed without requiringadditional user input, and the user receives a positive confirmationmessage reflecting that the transaction has been completed.

Advantageously, embodiments disclosed herein improve the security of alldevices and associated data. For example, by transmitting card databetween secure servers, the risks associated with storing data on a userdevice and transmitting the data using the user device are avoided.Furthermore, conventional approaches require the user to manually entercard data into a form. However, doing so may allow other users ordevices to capture the card data as the user enters the card data intothe form. By eliminating the need for the user to manually enter carddata, the security of the card data is enhanced. However, doing so mayallow other users or devices to capture the card data as the user entersthe card data into the form. By eliminating the need for the user tomanually enter card data into the form, the security of the card data isenhanced. Furthermore, the validation performed by the authenticationserver provides an additional safeguard to ensure that the correct carddata is being entered into the form. Additionally, the generation andfilling of virtual card numbers into the form protects the security ofthe actual account number of the contactless card, as conventionalsolutions require providing the actual account number of the contactlesscard into the form.

With general reference to notations and nomenclature used herein, one ormore portions of the detailed description which follows may be presentedin terms of program procedures executed on a computer or network ofcomputers. These procedural descriptions and representations are used bythose skilled in the art to most effectively convey the substances oftheir work to others skilled in the art. A procedure is here, andgenerally, conceived to be a self-consistent sequence of operationsleading to a desired result. These operations are those requiringphysical manipulations of physical quantities. Usually, though notnecessarily, these quantities take the form of electrical, magnetic, oroptical signals capable of being stored, transferred, combined,compared, and otherwise manipulated. It proves convenient at times,principally for reasons of common usage, to refer to these signals asbits, values, elements, symbols, characters, terms, numbers, or thelike. It should be noted, however, that all of these and similar termsare to be associated with the appropriate physical quantities and aremerely convenient labels applied to those quantities.

Further, these manipulations are often referred to in terms, such asadding or comparing, which are commonly associated with mentaloperations performed by a human operator. However, no such capability ofa human operator is necessary, or desirable in most cases, in any of theoperations described herein that form part of one or more embodiments.Rather, these operations are machine operations. Useful machines forperforming operations of various embodiments include digital computersas selectively activated or configured by a computer program storedwithin that is written in accordance with the teachings herein, and/orinclude apparatus specially constructed for the required purpose or adigital computer. Various embodiments also relate to apparatus orsystems for performing these operations. These apparatuses may bespecially constructed for the required purpose. The required structurefor a variety of these machines will be apparent from the descriptiongiven.

Reference is now made to the drawings, wherein like reference numeralsare used to refer to like elements throughout. In the followingdescription, for the purpose of explanation, numerous specific detailsare set forth in order to provide a thorough understanding thereof. Itmay be evident, however, that the novel embodiments can be practicedwithout these specific details. In other instances, well-knownstructures and devices are shown in block diagram form in order tofacilitate a description thereof. The intention is to cover allmodification, equivalents, and alternatives within the scope of theclaims.

FIG. 1A depicts a schematic of an exemplary system 100, consistent withdisclosed embodiments. As shown, the system 100 includes one or morecontactless cards 101, one or more mobile devices 110, an authenticationserver 120, a virtual account number server 140, and one or moremerchant servers 150. The contactless cards 101 are representative ofany type of payment cards, such as a credit card, debit card, ATM card,gift card, and the like. The contactless cards 101 may comprise one ormore communications interfaces 107, such as a radio frequencyidentification (RFID) chip, configured to communicate with the mobiledevices 110 via NFC, the EMV standard, or other short-range protocols inwireless communication. Although NFC is used as an examplecommunications protocol, the disclosure is equally applicable to othertypes of wireless communications, such as the EMV standard, Bluetooth,and/or Wi-Fi. The mobile devices 110 are representative of any type ofnetwork-enabled computing devices, such as smartphones, tabletcomputers, wearable devices, laptops, portable gaming devices, and thelike. The servers 120, 140, 150 are representative of any type ofcomputing device, such as a server, workstation, compute cluster, cloudcomputing platform, virtualized computing system, and the like.

As shown, a memory 111 of the mobile device 110 includes an instance ofan operating system (OS) 112. Example operating systems 112 include theAndroid® OS, iOS®, Linux®, and Windows® operating systems. As shown, theOS 112 includes one or more merchant applications 113. The merchantapplications 113 are representative of any type of application where auser may provide payment information to complete a transaction. Forexample, the merchant applications 113 may allow the users to select andpurchase goods, products, and/or services. In one embodiment, themerchant applications 113 may be web-based applications that areaccessed using a web browser (not pictured). For example, in web-basedapplications, the web browser may access a website of the merchantand/or progressive web applications provided by the merchant.

As shown, the merchant applications 113 include a one-tap module 114, amerchant identifier 115, and a transaction identifier 116. As describedin greater detail herein, the one-tap module 114 is software, hardware,and/or a combination of software and hardware that allows users to payfor transactions initiated in the merchant applications 113 using asingle tap of the contactless card 101 to the mobile device 110. Themerchant identifier 115 is a unique identifier associated with amerchant and/or a merchant server 150 associated with the merchant. Thetransaction identifier 116 uniquely identifies a given transaction. Forexample, the transaction identifier 116 may be a unique alphanumericidentifier, a unique session alphanumeric identifier, a file, etc. Thetransaction identifier 116 may be generated by the correspondingmerchant server 150 and transmitted to the merchant application 113and/or generated by the merchant application 113 and transmitted to thecorresponding merchant server 150.

Generally, a user may use the merchant application 113 (and/or amerchant website in embodiments where the application 113 is a webbrowser) to select one or more items and/or services for purchase. Whenthe user has selected the desired items and/or services, the user mayencounter an interface for completing the transaction (e.g., a cartpage, a checkout page, etc.) in the merchant application 113.Conventionally, the user is required to manually enter their name, cardnumber, expiration date, CVV, and/or address information into themerchant application 113 to complete the purchase. Furthermore,conventional solutions may require the user to log into their account inthe merchant application 113 (e.g., using a login/password, biometriccredentials, etc.). Advantageously, however, the one-tap module 114 mayfacilitate one-tap checkout (e.g., payment) using the contactless card101, regardless of whether the user has logged into their account in themerchant application 113. Generally, the one-tap module 114 may output anotification in the interface for completing the transaction. Thenotification may instruct the user to tap the contactless card 101 tothe mobile device 110, thereby bringing the contactless card 101sufficiently close to the card reader 119 of the mobile device 110 toenable data transfer (e.g., NFC data transfer, Bluetooth data transfer,etc.) between the communications interface 107 of the contactless card101 and the card reader 119 of the mobile device 110. In someembodiments, the mobile device 110 may trigger the card reader 119 viaan application program interface (API) call. In one example, the mobiledevice 110 triggers the card reader via an API call responsive to theuser tapping or otherwise selecting an element of the user interface,such as a form field. In addition and/or alternatively, the mobiledevice 110 may trigger the card reader 119 based on periodically pollingthe card reader 119. More generally, the mobile device 110 may triggerthe card reader 119 to engage in communications using any feasiblemethod.

After communication has been established between mobile device 110 andcontactless card 101, the applet 103 executing on a processor (notpictured) of the contactless card 101 generates and transmits encrypteddata 106 to the mobile device 110 via the communications interface 107.For example, the applet 103 of the contactless card 101 may use acryptographic algorithm to generate a cryptographic payload of encrypteddata 106 based at least in part on the private key 104 stored in thememory 102 of the contactless card 101. In such an embodiment, theprivate key 104 and some other piece of data (e.g., the customeridentifier 105, an account identifier, etc.) may be provided as theinput to the cryptographic algorithm, which outputs the encrypted data106. Generally, the applet 103 may use any type of cryptographicalgorithm and/or system to generate the encrypted data 106, and the useof a specific cryptographic algorithm as an example herein should not beconsidered limiting of the disclosure. In some embodiments, the applet103 may perform encryption using a key diversification technique togenerate the encrypted data 106. Examples of key diversificationtechniques are described in U.S. patent application Ser. No. 16/205,119,filed Nov. 29, 2018. The aforementioned patent application isincorporated by reference herein in its entirety.

Once generated, the applet 103 may transmit the encrypted data 106 tothe one-tap module 114 of the mobile device 110, e.g., via NFC. In someembodiments, the one-tap module 114 may require the user to log intotheir account in the account data 124 associated with the contactlesscard 101 (e.g., provide a login/password and/or biometric credentials).The one-tap module 114 may transmit the encrypted data 106, the merchantidentifier 115, and the transaction identifier 116 to the authenticationapplication 123 of the authentication server 120. In some embodiments,the one-tap module 114 may transmit additional data describing themobile device 110, such as a software fingerprint of the mobile device110, location (e.g., global positioning system (GPS)) data of the mobiledevice 110, a unique identifier of the mobile device 110, etc.

Once received, the authentication application 123 may then authenticatethe encrypted data 106. For example, the authentication application 123may attempt to decrypt the encrypted data 106 using a copy of theprivate key 104 stored in the memory 122 of the authentication server120. The private key 104 may be identical to the private key 104 storedin the memory 102 of the contactless card 101, where each contactlesscard 101 is manufactured to include a unique private key 104 (and theauthentication server 120 stores a corresponding copy of each uniqueprivate key 104). Therefore, the authentication application 123 maysuccessfully decrypt the encrypted data 106, thereby verifying theencrypted data 106. Although the private key 104 is depicted as beingstored in the memory 122, the private key 104 may be stored elsewhere,such as in a secure element and/or a hardware security module (HSM). Insuch embodiments, the secure element and/or the HSM may decrypt theencrypted data 106 using the private key 104 and a cryptographicfunction.

For example, as stated, the customer identifier 105 may be used togenerate the encrypted data 106. In such an example, the authenticationapplication 123 may decrypt the encrypted data 106 using the private key104 of the authentication server 120. If the result of the decryptionyields the customer identifier 105 associated with the account in theaccount data 124, the authentication application 123 verifies theencrypted data 106 and instructs the VAN generator 142 to generatevirtual card data for the account associated with the contactless card101. If the authentication application 123 is unable to decrypt theencrypted data to yield the expected result (e.g., the customeridentifier 105 of the account associated with the contactless card 101),the authentication application 123 does not validate the encrypted data106. Due to the failed verification, the authentication application 123does not instruct the VAN generator 142 to generate virtual card data topreserve the security of the associated account.

In some embodiments, the authentication application 123 processes theadditional data received from the mobile device 110 as a condition toinstructing the VAN generator 142 to generate the virtual card data.Some such embodiments include where the user is not logged into themerchant account and/or the account in the account data 124. Forexample, the authentication application 123 may determine whether thedevice identifier of the mobile device 110 is specified as a knowndevice identifier for the associated account in the account data 124. Ifthe device identifier is not a known identifier, the authenticationapplication 123 may refrain from instructing the VAN generator 142 togenerate the virtual card data. Otherwise, the authenticationapplication 123 may instruct the VAN generator 142 to generate thevirtual card data. As another example, the authentication application123 may determine whether the software fingerprint matches a knownsoftware fingerprint for the associated account in the account data 124.If the software fingerprint is not a known software fingerprint, theauthentication application 123 may refrain from instructing the VANgenerator 142 to generate the virtual card data. Otherwise, theauthentication application 123 may instruct the VAN generator 142 togenerate the virtual card data. As yet another example, theauthentication application 123 may determine whether the GPS coordinatesindicate the user is at home, at work, or some other known addressassociated with the account in the account data 124. If the location ofthe device is not within a threshold distance of the known address, theauthentication application 123 may refrain from instructing the VANgenerator 142 to generate the virtual card data. Otherwise, theauthentication application 123 may instruct the VAN generator 142 togenerate the virtual card data. Further still, the authenticationapplication 123 may determine whether the user has previously madepurchases with the merchant associated with the received merchantidentifier 115. If the user has not made a previous purchase with themerchant, the authentication application 123 may refrain frominstructing the VAN generator 142 to generate the virtual card data.Otherwise, the authentication application 123 may instruct the VANgenerator 142 to generate the virtual card data.

FIG. 1B depicts an embodiment where the authentication application 123validates the encrypted data 106 and instructs the virtual accountnumber (VAN) generator 142 in the memory 141 of the virtual accountnumber server 140 to generate virtual card data 126 comprising a virtualaccount number, expiration date, and CVV for the account associated withthe contactless card 101. In some embodiments, the VAN generator 142generates the virtual account number, the expiration date, and the CVV.In other embodiments, the VAN generator 142 generates the virtualaccount number and selects an existing expiration date and/or CVV (e.g.,from the account data 124). For example, the existing expiration dateand/or CVV may be the expiration date and/or CVV of the contactless card101, or another card associated with the account in the account data124. The VAN generator 142 may further receive the name of the accountholder and one or more known addresses (e.g., a billing address,shipping address, etc.) from the account in the account data 124associated with the contactless card 101. In at least one embodiment,the card data 126 including the virtual account number generated by theVAN generator 142 is restricted to the merchant associated with themerchant identifier 115. The virtual account number and/or card data 126may further include other restrictions (e.g., time restrictions, amountrestrictions, etc.). Once generated, the VAN generator 142 may transmitthe virtual card data 126, the merchant identifier 115, and thetransaction identifier 116 to the merchant server 150. The VAN generator142 and/or the authentication server 120 may further transmit the nameof the account holder, the billing address, and the shipping address tothe merchant server 150. In one embodiment, the VAN generator 142determines a location of the merchant server 150 based on the merchantidentifier 115 (e.g., in a lookup table associating merchant identifiers115 with a corresponding merchant server 150).

FIG. 1C depicts an embodiment where the merchant server 150 receives thevirtual card data 126, the merchant identifier 115, the transactionidentifier 116, and any other data (e.g., the account holder's name andaddresses) from the VAN generator 142 and/or the authentication server120. Generally, the merchant server 150 may process the transactionusing the data received from the VAN generator 142 and/or theauthentication server 120. More specifically, the merchant server 150may generate a transaction record 152 in the transaction database 151using the received virtual account number, expiration date, CVV, name,and/or addresses. The transaction record 152 in the transaction database151 may further specify the transaction identifier 116. Doing so usesthe virtual card data 126 to pay for the transaction without requiringthe user to input any payment information using the merchant application113 executing on the mobile device 110. Instead, the transaction is paidfor and processed using the securely generated and transmitted virtualcard data 126.

As shown, the merchant server 150 may generate a confirmation 153indicating that payment for the transaction was received and thetransaction has been processed. The merchant server 150 may transmit theconfirmation 153 to the merchant application 113, which may output theconfirmation 153 on a display of the mobile device 110. In otherembodiments, the confirmation 153 may be an email confirmation, textmessage confirmation, push notification, etc. Doing so informs the userthat the transaction has been completed and may include additionalinformation regarding the delivery of items, rendering of services, etc.

FIG. 2A is a schematic 200 depicting an example embodiment of tappingthe contactless card 101 for one-tap payment. As shown, the merchantapplication 113 executing on the mobile device 110 displays a graphicaluser interface (GUI) to complete a purchase. For example, the GUI may bea shopping cart page, checkout page, or any other page of the merchantapplication 113. As shown, a notification 201 instructs a user to tapthe contactless card 101 to the mobile device 110 to pay for the itemsin their shopping cart using one-tap payment. Once the tap is detected,as shown in the schematic 210 of FIG. 2B, the merchant application 113may output a notification 202 indicating that a secure virtual number isbeing generated.

As stated, once the user taps the contactless card 101 to the mobiledevice 110, the contactless card 101 generates the encrypted data 106and transmits the encrypted data 106 to the mobile device 110. Oncereceived, the one-tap module 114 transmits the encrypted data 106,merchant ID 115, and transaction ID 116 to the authentication server120. The authentication application 123 may then verify the encrypteddata 106 by decrypting the encrypted data 106 with the private key 104stored in the memory 122 of the server 120. Once verified, theauthentication application 123 instructs the VAN generator 142 togenerate the virtual card data 126 (e.g., a virtual card number,expiration date, and/or CVV). As stated, in some embodiments, the VANgenerator 142 may generate the virtual card number and retrieve theexpiration date and/or CVV from the account data 124. The VAN generator142 may also receive the merchant ID 115, the transaction ID 116, andadditional data describing the user (e.g., names, billing address,shipping address, etc.) from the account data 124. The VAN generator 142may then transmit the virtual card data 126, the merchant ID 115,transaction ID 116, and any usernames and/or addresses to the merchantserver 150. The merchant server 150 may then process the transactionusing the data received from the VAN generator 142, e.g., by generatinga transaction record 152 in the transaction database 151 using at leastthe received virtual card number, expiration date, CVV. The transactionrecord 152 may further include the user's name, billing address,shipping address, and an indication of each item and/or servicepurchased. The merchant server 150 may then transmit an orderconfirmation to the mobile device 110. FIG. 2D is a schematic 230depicting an example confirmation outputted by the merchant application113 on the mobile device 110.

In some embodiments, the merchant server 150 may require resolution ofdata conflicts before processing the transaction using the data receivedfrom the VAN generator 142. For example, the account data 124 mayspecify a billing address of “123 Main St.” for the user's account,whereas the user's profile in the merchant server 150 may specify “300Bowles Dr.” as the billing address of the user's account. Therefore, asdepicted in the schematic 220 of FIG. 2C, the merchant server 150 maycause the merchant application 113 to output the notification 203 on themobile device 110. As shown, the notification 203 allows the user toselect one of the two different addresses. Once selected, the merchantapplication 113 transmits an indication of the selected address to themerchant server 150. The merchant server 150 may then process thetransaction using the selected address. Although an address is used asan example, the merchant server 150 and/or the merchant application 113may similarly resolve data conflicts for other data types (e.g., names,shipping addresses, etc.).

FIG. 3 illustrates an embodiment of a logic flow 300. The logic flow 300may be representative of some or all of the operations executed by oneor more embodiments described herein. For example, the logic flow 300may include some or all of the operations to use a contactless card toperform one-tap payment. Embodiments are not limited in this context.

As shown, the logic flow 300 begins at block 305, where a useroptionally provides authentication credentials to authenticate a useraccount in the merchant application 113, where the merchant application113 includes the one-tap module 114 for supporting one-tap checkout asdescribed herein. However, as stated, in some embodiments, the user maynot authenticate into their account with the merchant application 113.At block 310, the user may select one or more items and/or services topurchase as part of a transaction. For example, the user may specify torequest a car service to drive them from their home to the airport. Asanother example, the user may specify to order food items for deliveryto their office. As stated, the merchant application 113 may beassociated with a unique merchant ID 115. Similarly, the user's selecteditems and/or services may be associated with a transaction ID 116. Asthe user selects and/or removes items and/or services from theirshopping cart, the merchant application 113 may transmit an indicationof the transaction ID 116 and the selected and/or removed items to themerchant server 150, thereby allowing the merchant server 150 to beaware of what items and/or services are associated with a giventransaction ID 116. At block 315, the one-tap module 114 of the merchantapplication 113 outputs a notification specifying to tap a contactlesscard 101 to the mobile device 110. In one embodiment, the one-tap module114 outputs the notification upon determining the merchant application113 outputs an element (e.g., a form, a form field, etc.) that isassociated with completing a transaction and/or paying for atransaction.

At block 320, a user taps the contactless card 101 to the mobile device110 to cause the contactless card 101 to generate and transmit encrypteddata 106. The applet 103 of the contactless card 101 may then generatethe encrypted data 106 using the private key 104, input data (e.g., thecustomer identifier 105), and a cryptographic algorithm. The applet 103may then transmit the encrypted data 106 to the mobile device 110. Atblock 325, the one-tap module 114 and/or the merchant application 113may receive the encrypted data 106 from the communications interface 107of the contactless card. At block 330, the one-tap module 114 and/or themerchant application 113 transmits the encrypted data 106, merchantidentifier 115, and the transaction identifier 116 to the authenticationserver 120.

At block 335, the authentication application 123 decrypts the encrypteddata 106 using the private key 104 in the memory 122 of theauthentication server 120 to validate the encrypted data 106. At block340, the authentication application 123 transmits an indication to theVAN generator 142 specifying to generate card data comprising a virtualaccount number, expiration date, and CVV. The authentication application123 may further transmit the merchant identifier 115 and/or thetransaction identifier 116 to the VAN generator 142. At block 345, theVAN generator 142 generates the virtual account number, expiration date,and CVV. At block 350, the VAN generator 142 transmits the virtualaccount number, expiration date, CVV, merchant ID 115, and transactionID 116 to the mobile device 110. The VAN generator 142 may furtherinclude the name, billing address, and shipping address of the accountholder, which may be stored locally by the VAN generator 142 and/orreceived from the authentication server 120.

At block 355, the merchant server 150 processes the transactionassociated with the transaction ID 116 using the data received from theVAN generator 142. More specifically, the merchant server 150 processespayment for the transaction using at least the virtual card number,expiration date, and CVV generated by the VAN generator 142. As stated,the merchant server 150 may process the transaction payment bygenerating a transaction record 152 in the transaction database 151using at least the received virtual card number, expiration date, CVV.The transaction record 152 may further include the user's name, billingaddress, shipping address, and an indication of each item and/or serviceassociated with the transaction ID 116. At block 360, the merchantserver 150 may transmit a payment confirmation to the merchantapplication 113 on the mobile device. The confirmation may generallyindicate that the payment has been processed using the virtual card datagenerated by the VAN generator.

FIG. 4 illustrates an embodiment of a logic flow 400. The logic flow 400may be representative of some or all of the operations executed by oneor more embodiments described herein. For example, the logic flow 500may include some or all of the operations performed to authorize aone-tap payment using the contactless card 101. Embodiments are notlimited in this context.

As shown, the logic flow 400 begins at block 405, where the one-tapmodule 114 and/or the merchant application 113 transmits the encrypteddata 106 generated by the contactless card 101, the merchant ID 115,transaction ID 116, and a device identifier to the authentication server120. As stated, the device identifier may be a software fingerprint ofthe mobile device 110, a unique identifier of the mobile device 110(e.g., a medium access control (MAC) address), and the like. At block410, the authentication application 123 may determine that the receiveddevice identifier is not associated with the account of the contactlesscard 101. For example, the account data 124 may include known deviceidentifiers for a given account. If the received device identifier isnot specified as a known device identifier in the account data 124, theauthentication application 123 may require additional information topreserve account security. As such, the authentication application 123may instruct the one-tap module 114 to output an indication to receiveauthentication credentials for the account in the account data 124. Forexample, the one-tap module 114 may output a notification specifyingthat the user provides their fingerprint as biometric input toauthenticate into their account associated with the account in theaccount data 124. As another example, the one-tap module 114 may outputa notification specifying that the user provides the login and passwordassociated with the account in the account data 124. In otherembodiments, the user may log into the account using FaceID, otherbiometric identifiers, or any other type of credential.

At block 415, the user provides credentials (e.g., biometric input,login/password, etc.) for the account in the account data 124 to theone-tap module 114 and/or the merchant application 113. The one-tapmodule 114 may include logic to verify the received credentials. Inother embodiments, the one-tap module 114 may transmit the receivedcredentials to the authentication server 120. At block 420, theauthentication application 123 authenticates the received accountcredentials and the encrypted data 106 generated by the contactless card101. The authentication application 123 may determine whether thereceived account credentials match credentials for the account stored inthe account data 124 and decrypt the encrypted data 106 using theprivate key 104. At block 425, the authentication server 120 maydetermine to instruct the VAN generator 142 to generate a virtual cardnumber, expiration date, and CVV. The authentication server 120 mayfurther transmit, with the instruction, a name, billing address, andshipping address from the account data 124 to the VAN generator 142.

FIG. 5 illustrates an embodiment of a logic flow 500. The logic flow 500may be representative of some or all of the operations executed by oneor more embodiments described herein. For example, the logic flow 500may include some or all of the operations to provide one-tap payment fortransactions using a contactless card. Embodiments are not limited inthis context.

As shown, the logic flow 500 begins at block 505, where the merchantserver 150 generates a transaction identifier 116 for a transaction. Asstated, the transaction identifier 116 may be any type of identifier,such as a unique alphanumeric identifier, a unique session alphanumericidentifier, a file, etc. At block 510, the merchant application 113receives the transaction identifier 116 from the merchant server 150 viathe network 130. The merchant application 113 and/or the one-tap module114 may transmit the received transaction identifier 116 with theencrypted data 106 to the authentication server 120. At block 515, themerchant application 113 transmits indications of items and/or servicesadded and/or removed from the user's shopping cart for the transactionassociated with the transaction identifier 116. At block 520, themerchant server 150 receives the virtual card data 126, userinformation, and transaction identifier 116 from the VAN generator 142.At block 525, the merchant server processes payment for the transactionassociated with the transaction identifier 116 by generating atransaction record in the transaction database 151.

FIG. 6 illustrates an embodiment of a logic flow 600. The logic flow 600may be representative of some or all of the operations executed by oneor more embodiments described herein. For example, the logic flow 600may include some or all of the operations performed by the merchantapplication 113 and/or the merchant server 150. Embodiments are notlimited in this context.

As shown, the logic flow 600 begins at block 605, where the merchantserver 150 receives the virtual card data 126 (e.g., virtual accountnumber, expiration date, and CVV), account holder data (e.g., name,billing address, shipping address, etc.), and transaction ID 116 fromthe VAN generator 142. At block 610, the merchant server 150 determinesthat at least one element of the received data is not like at least oneelement of user data in a user profile associated with the merchant. Forexample, the received mailing and/or billing addresses may not match anyaddresses specified in the user profile.

At block 615, the merchant server 150 instructs the merchant application113 to output indications of the data elements identified at block 610.For example, the merchant application 113 may output a list ofaddresses. At block 620, the merchant application 113 receives a userselection of one of the data elements (e.g., a first address outputtedat block 615). At block 625, the merchant application 113 transmits anindication of the data element selected at block 620 to the merchantserver 150. At block 630, the merchant server 150 processes thetransaction using the data received from the VAN generator 142 and thedata element selected by the user at block 620. More specifically, themerchant server 150 generates a transaction record for the transactionin the transaction database 151.

FIG. 7 illustrates an embodiment of an exemplary computing architecture700 comprising a computing system 702 that may be suitable forimplementing various embodiments as previously described. In variousembodiments, the computing architecture 700 may comprise or beimplemented as part of an electronic device. In some embodiments, thecomputing architecture 700 may be representative, for example, of asystem that implements one or more components of the system 100. In someembodiments, computing system 702 may be representative, for example, ofthe contactless card 101, mobile devices 110, authentication server 120,the virtual account number server 140, and/or the merchant server 150 ofthe system 100. The embodiments are not limited in this context. Moregenerally, the computing architecture 700 is configured to implement alllogic, applications, systems, methods, apparatuses, and functionalitydescribed herein with reference to FIGS. 1-6 .

As used in this application, the terms “system” and “component” and“module” are intended to refer to a computer-related entity, eitherhardware, a combination of hardware and software, software, or softwarein execution, examples of which are provided by the exemplary computingarchitecture 700. For example, a component can be, but is not limited tobeing, a process running on a computer processor, a computer processor,a hard disk drive, multiple storage drives (of optical and/or magneticstorage medium), an object, an executable, a thread of execution, aprogram, and/or a computer. By way of illustration, both an applicationrunning on a server and the server can be a component. One or morecomponents can reside within a process and/or thread of execution, and acomponent can be localized on one computer and/or distributed betweentwo or more computers. Further, components may be communicativelycoupled to each other by various types of communications media tocoordinate operations. The coordination may involve the uni-directionalor bi-directional exchange of information. For instance, the componentsmay communicate information in the form of signals communicated over thecommunications media. The information can be implemented as signalsallocated to various signal lines. In such allocations, each message isa signal. Further embodiments, however, may alternatively employ datamessages. Such data messages may be sent across various connections.Exemplary connections include parallel interfaces, serial interfaces,and bus interfaces.

The computing system 702 includes various common computing elements,such as one or more processors, multi-core processors, co-processors,memory units, chipsets, controllers, peripherals, interfaces,oscillators, timing devices, video cards, audio cards, multimediainput/output (I/O) components, power supplies, and so forth. Theembodiments, however, are not limited to implementation by the computingsystem 702.

As shown in FIG. 7 , the computing system 702 comprises a processor 704,a system memory 706 and a system bus 708. The processor 704 can be anyof various commercially available computer processors, including withoutlimitation an AMD® Athlon®, Duron® and Opteron® processors; ARM®application, embedded and secure processors; IBM® and Motorola®DragonBall® and PowerPC® processors; IBM and Sony® Cell processors;Intel® Celeron®, Core®, Core (2) Duo®, Itanium®, Pentium®, Xeon®, andXScale® processors; and similar processors. Dual microprocessors,multi-core processors, and other multi processor architectures may alsobe employed as the processor 704.

The system bus 708 provides an interface for system componentsincluding, but not limited to, the system memory 706 to the processor704. The system bus 708 can be any of several types of bus structurethat may further interconnect to a memory bus (with or without a memorycontroller), a peripheral bus, and a local bus using any of a variety ofcommercially available bus architectures. Interface adapters may connectto the system bus 708 via a slot architecture. Example slotarchitectures may include without limitation Accelerated Graphics Port(AGP), Card Bus, (Extended) Industry Standard Architecture ((E)ISA),Micro Channel Architecture (MCA), NuBus, Peripheral ComponentInterconnect (Extended) (PCI(X)), PCI Express, Personal Computer MemoryCard International Association (PCMCIA), and the like.

The system memory 706 may include various types of computer-readablestorage media in the form of one or more higher speed memory units, suchas read-only memory (ROM), random-access memory (RAM), dynamic RAM(DRAM), Double-Data-Rate DRAM (DDRAM), synchronous DRAM (SDRAM), staticRAM (SRAM), programmable ROM (PROM), erasable programmable ROM (EPROM),electrically erasable programmable ROM (EEPROM), flash memory (e.g., oneor more flash arrays), polymer memory such as ferroelectric polymermemory, ovonic memory, phase change or ferroelectric memory,silicon-oxide-nitride-oxide-silicon (SONOS) memory, magnetic or opticalcards, an array of devices such as Redundant Array of Independent Disks(RAID) drives, solid state memory devices (e.g., USB memory, solid statedrives (SSD) and any other type of storage media suitable for storinginformation. In the illustrated embodiment shown in FIG. 7 , the systemmemory 706 can include non-volatile memory 710 and/or volatile memory712. A basic input/output system (BIOS) can be stored in thenon-volatile memory 710.

The computing system 702 may include various types of computer-readablestorage media in the form of one or more lower speed memory units,including an internal (or external) hard disk drive (HDD) 714, amagnetic floppy disk drive (FDD) 716 to read from or write to aremovable magnetic disk 718, and an optical disk drive 720 to read fromor write to a removable optical disk 722 (e.g., a CD-ROM or DVD). TheHDD 714, FDD 716 and optical disk drive 720 can be connected to thesystem bus 708 by a HDD interface 724, an FDD interface 726 and anoptical drive interface 728, respectively. The HDD interface 724 forexternal drive implementations can include at least one or both ofUniversal Serial Bus (USB) and IEEE 1394 interface technologies. Thecomputing system 702 is generally is configured to implement all logic,systems, methods, apparatuses, and functionality described herein withreference to FIGS. 1-6 .

The drives and associated computer-readable media provide volatileand/or nonvolatile storage of data, data structures, computer-executableinstructions, and so forth. For example, a number of program modules canbe stored in the drives and memory units 710, 712, including anoperating system 730, one or more application programs 732, otherprogram modules 734, and program data 736. In one embodiment, the one ormore application programs 732, other program modules 734, and programdata 736 can include, for example, the various applications and/orcomponents of the system 100, e.g., the applet 103, private keys 104,encrypted data 106, operating system 112, merchant applications 113, theone-tap module 114, the authentication application 123, the VANgenerator 142, and/or the merchant server 150.

A user can enter commands and information into the computing system 702through one or more wire/wireless input devices, for example, a keyboard738 and a pointing device, such as a mouse 740. Other input devices mayinclude microphones, infra-red (IR) remote controls, radio-frequency(RF) remote controls, game pads, stylus pens, card readers, dongles,finger print readers, gloves, graphics tablets, joysticks, keyboards,retina readers, touch screens (e.g., capacitive, resistive, etc.),trackballs, trackpads, sensors, styluses, and the like. These and otherinput devices are often connected to the processor 704 through an inputdevice interface 742 that is coupled to the system bus 708, but can beconnected by other interfaces such as a parallel port, IEEE 1394 serialport, a game port, a USB port, an IR interface, and so forth.

A monitor 744 or other type of display device is also connected to thesystem bus 708 via an interface, such as a video adaptor 746. Themonitor 744 may be internal or external to the computing system 702. Inaddition to the monitor 744, a computer typically includes otherperipheral output devices, such as speakers, printers, and so forth.

The computing system 702 may operate in a networked environment usinglogical connections via wire and/or wireless communications to one ormore remote computers, such as a remote computer 748. The remotecomputer 748 can be a workstation, a server computer, a router, apersonal computer, portable computer, microprocessor-based entertainmentappliance, a peer device or other common network node, and typicallyincludes many or all of the elements described relative to the computingsystem 702, although, for purposes of brevity, only a memory/storagedevice 750 is illustrated. The logical connections depicted includewire/wireless connectivity to a local area network (LAN) 752 and/orlarger networks, for example, a wide area network (WAN) 754. Such LANand WAN networking environments are commonplace in offices andcompanies, and facilitate enterprise-wide computer networks, such asintranets, all of which may connect to a global communications network,for example, the Internet. In embodiments, the network 130 of FIG. 1 isone or more of the LAN 752 and the WAN 754.

When used in a LAN networking environment, the computing system 702 isconnected to the LAN 752 through a wire and/or wireless communicationnetwork interface or adaptor 756. The adaptor 756 can facilitate wireand/or wireless communications to the LAN 752, which may also include awireless access point disposed thereon for communicating with thewireless functionality of the adaptor 756.

When used in a WAN networking environment, the computing system 702 caninclude a modem 758, or is connected to a communications server on theWAN 754, or has other means for establishing communications over the WAN754, such as by way of the Internet. The modem 758, which can beinternal or external and a wire and/or wireless device, connects to thesystem bus 708 via the input device interface 742. In a networkedenvironment, program modules depicted relative to the computing system702, or portions thereof, can be stored in the remote memory/storagedevice 750. It will be appreciated that the network connections shownare exemplary and other means of establishing a communications linkbetween the computers can be used.

The computing system 702 is operable to communicate with wired andwireless devices or entities using the IEEE 802 family of standards,such as wireless devices operatively disposed in wireless communication(e.g., IEEE 802.16 over-the-air modulation techniques). This includes atleast Wi-Fi (or Wireless Fidelity), WiMax, and Bluetooth™ wirelesstechnologies, among others. Thus, the communication can be a predefinedstructure as with a conventional network or simply an ad hoccommunication between at least two devices. Wi-Fi networks use radiotechnologies called IEEE 802.11x (a, b, g, n, etc.) to provide secure,reliable, fast wireless connectivity. A Wi-Fi network can be used toconnect computers to each other, to the Internet, and to wire networks(which use IEEE 802.3-related media and functions).

Various embodiments may be implemented using hardware elements, softwareelements, or a combination of both. Examples of hardware elements mayinclude processors, microprocessors, circuits, circuit elements (e.g.,transistors, resistors, capacitors, inductors, and so forth), integratedcircuits, application specific integrated circuits (ASIC), programmablelogic devices (PLD), digital signal processors (DSP), field programmablegate array (FPGA), logic gates, registers, semiconductor device, chips,microchips, chip sets, and so forth. Examples of software may includesoftware components, programs, applications, computer programs,application programs, system programs, machine programs, operatingsystem software, middleware, firmware, software modules, routines,subroutines, functions, methods, procedures, software interfaces,application program interfaces (API), instruction sets, computing code,computer code, code segments, computer code segments, words, values,symbols, or any combination thereof. Determining whether an embodimentis implemented using hardware elements and/or software elements may varyin accordance with any number of factors, such as desired computationalrate, power levels, heat tolerances, processing cycle budget, input datarates, output data rates, memory resources, data bus speeds and otherdesign or performance constraints.

One or more aspects of at least one embodiment may be implemented byrepresentative instructions stored on a machine-readable medium whichrepresents various logic within the processor, which when read by amachine causes the machine to fabricate logic to perform the techniquesdescribed herein. Such representations, known as “IP cores” may bestored on a tangible, machine readable medium and supplied to variouscustomers or manufacturing facilities to load into the fabricationmachines that make the logic or processor. Some embodiments may beimplemented, for example, using a machine-readable medium or articlewhich may store an instruction or a set of instructions that, ifexecuted by a machine, may cause the machine to perform a method and/oroperations in accordance with the embodiments. Such a machine mayinclude, for example, any suitable processing platform, computingplatform, computing device, processing device, computing system,processing system, computer, processor, or the like, and may beimplemented using any suitable combination of hardware and/or software.The machine-readable medium or article may include, for example, anysuitable type of memory unit, memory device, memory article, memorymedium, storage device, storage article, storage medium and/or storageunit, for example, memory, removable or non-removable media, erasable ornon-erasable media, writeable or re-writeable media, digital or analogmedia, hard disk, floppy disk, Compact Disk Read Only Memory (CD-ROM),Compact Disk Recordable (CD-R), Compact Disk Rewriteable (CD-RW),optical disk, magnetic media, magneto-optical media, removable memorycards or disks, various types of Digital Versatile Disk (DVD), a tape, acassette, or the like. The instructions may include any suitable type ofcode, such as source code, compiled code, interpreted code, executablecode, static code, dynamic code, encrypted code, and the like,implemented using any suitable high-level, low-level, object-oriented,visual, compiled and/or interpreted programming language.

The foregoing description of example embodiments has been presented forthe purposes of illustration and description. It is not intended to beexhaustive or to limit the present disclosure to the precise formsdisclosed. Many modifications and variations are possible in light ofthis disclosure. It is intended that the scope of the present disclosurebe limited not by this detailed description, but rather by the claimsappended hereto. Future filed applications claiming priority to thisapplication may claim the disclosed subject matter in a differentmanner, and may generally include any set of one or more limitations asvariously disclosed or otherwise demonstrated herein.

What is claimed is:
 1. A method, comprising: receiving, by a processorfrom a merchant application executing on a client device: (i) a merchantidentifier of a merchant associated with the merchant application, (ii)a transaction identifier of a transaction, (iii) encrypted data, and(iv) a location of the client device; verifying, by the processor, theencrypted data by decrypting the encrypted data based at least in parton a key for a contactless card; generating, by the processor, a virtualaccount number based on the verification of the encrypted data; andtransmitting, by the processor, the merchant identifier, the transactionidentifier, the virtual account number, an expiration date associatedwith the virtual account number, and a card verification value (CVV)associated with the virtual account number to a merchant serverassociated with the merchant to process the transaction using thetransaction identifier, the virtual account number, the expiration date,and the CVV.
 2. The method of claim 1, further comprising: determining,by the processor, that the contactless card has been used to make aprevious purchase with the merchant, wherein the virtual account numberis generated based on the determination that the contactless card haspreviously been used to make a purchase with the merchant.
 3. The methodof claim 1, further comprising: determining, by the processor, that thelocation of the client device is within a threshold distance of a knownlocation associated with the contactless card, wherein the virtualaccount number is generated based on the determination that the clientdevice is within the threshold distance of the known location.
 4. Themethod of claim 1, further comprising: determining, by the processor,that a device identifier received from the client device is associatedwith a user account associated with the contactless card, wherein thevirtual account number is generated based on the determination that thedevice identifier is associated with the contactless card.
 5. The methodof claim 1, wherein the expiration date and the CVV comprise one or moreof: (i) an expiration date and a CVV generated by the processor, and(ii) an expiration date and a CVV of the contactless card received bythe processor from an account database.
 6. The method of claim 1,further comprising: receiving, by the processor, a software fingerprintof the client device; and determining, by the processor, that thesoftware fingerprint matches a known software fingerprint associatedwith the contactless card, wherein the virtual account number isgenerated based on the determination that the software fingerprintmatches the known software fingerprint.
 7. The method of claim 1,further comprising: receiving, by the processor from the client device,authentication information for a user account associated with thecontactless card, the authentication information comprising one or moreof: (i) a username and a password, (ii) biometric credentials; andverifying, by the processor, the authentication information for the useraccount, wherein the virtual account number is generated based on theverification of the authentication information.
 8. A non-transitorycomputer-readable storage medium, the computer-readable storage mediumincluding instructions that when executed by a processor, cause theprocessor to: receive, from a merchant application executing on a clientdevice: (i) a merchant identifier of a merchant associated with themerchant application, (ii) a transaction identifier of a transaction,(iii) encrypted data, and (iv) a location of the client device; verifythe encrypted data by decrypting the encrypted data based at least inpart on a key for a contactless card; generate a virtual account numberbased on the verification of the encrypted data; and transmit themerchant identifier, the transaction identifier, the virtual accountnumber, an expiration date associated with the virtual account number,and a card verification value (CVV) associated with the virtual accountnumber to a merchant server associated with the merchant to process thetransaction using the transaction identifier, the virtual accountnumber, the expiration date, and the CVV.
 9. The computer-readablestorage medium of claim 8, wherein the instructions further cause theprocessor to: determine that the contactless card has been used to makea previous purchase with the merchant, wherein the virtual accountnumber is generated based on the determination that the contactless cardhas previously been used to make a purchase with the merchant.
 10. Thecomputer-readable storage medium of claim 8, wherein the instructionsfurther cause the processor to: determine that the location of theclient device is within a threshold distance of a known locationassociated with the contactless card, wherein the virtual account numberis generated based on the determination that the client device is withinthe threshold distance of the known location.
 11. The computer-readablestorage medium of claim 8, wherein the instructions further cause theprocessor to: determine that a device identifier received from theclient device is associated with a user account associated with thecontactless card, wherein the virtual account number is generated basedon the determination that the device identifier is associated with thecontactless card.
 12. The computer-readable storage medium of claim 8,wherein the expiration date and the CVV comprise one or more of: (i) anexpiration date and a CVV generated by the processor, and (ii) anexpiration date and a CVV of the contactless card received by theprocessor from an account database.
 13. The computer-readable storagemedium of claim 8, wherein the instructions further cause the processorto: receive a software fingerprint of the client device; and determinethat the software fingerprint matches a known software fingerprintassociated with the contactless card, wherein the virtual account numberis generated based on the determination that the software fingerprintmatches the known software fingerprint.
 14. The computer-readablestorage medium of claim 8, wherein the instructions further cause theprocessor to: receive, from the client device, authenticationinformation for a user account associated with the contactless card, theauthentication information comprising one or more of: (i) a username anda password, (ii) biometric credentials; and verify the authenticationinformation for the user account, wherein the virtual account number isgenerated based on the verification of the authentication information.15. A computing apparatus comprising: a processor; and a memory storinginstructions that, when executed by the processor, cause the processorto: receive, from a merchant application executing on a client device:(i) a merchant identifier of a merchant associated with the merchantapplication, (ii) a transaction identifier of a transaction, (iii)encrypted data, and (iv) a location of the client device; verify theencrypted data by decrypting the encrypted data based at least in parton a key for a contactless card; generate a virtual account number basedon the verification of the encrypted data; and transmit the merchantidentifier, the transaction identifier, the virtual account number, anexpiration date associated with the virtual account number, and a cardverification value (CVV) associated with the virtual account number to amerchant server associated with the merchant to process the transactionusing the transaction identifier, the virtual account number, theexpiration date, and the CVV.
 16. The computing apparatus of claim 15,wherein the instructions further cause the processor to: determine thatthe contactless card has been used to make a previous purchase with themerchant, wherein the virtual account number is generated based on thedetermination that the contactless card has previously been used to makea purchase with the merchant.
 17. The computing apparatus of claim 15,wherein the instructions further configure the apparatus to: determine,by the processor, that the location of the client device is within athreshold distance of a known location associated with the contactlesscard, wherein the virtual account number is generated based on thedetermination that the client device is within the threshold distance ofthe known location.
 18. The computing apparatus of claim 15, wherein theinstructions further cause the processor to: determine that a deviceidentifier received from the client device is associated with a useraccount associated with the contactless card, wherein the virtualaccount number is generated based on the determination that the deviceidentifier is associated with the contactless card.
 19. The computingapparatus of claim 15, wherein the expiration date and the CVV compriseone or more of: (i) an expiration date and a CVV generated by theprocessor, and (ii) an expiration date and a CVV of the contactless cardreceived by the processor from an account database.
 20. The computingapparatus of claim 15, wherein the instructions further cause theprocessor to: receive a software fingerprint of the client device; anddetermine that the software fingerprint matches a known softwarefingerprint associated with the contactless card, wherein the virtualaccount number is generated based on the determination that the softwarefingerprint matches the known software fingerprint.